HARQ is a known communication protocol used in packet data communication systems for improving transmission reliability. HARQ combines forward error correction (FEC) and automatic repeat request (ARQ) techniques. In ARQ, a transmitter sends a plurality of data packets through a communications channel to a receiver, and adds, at least, an error detection information (such as a redundancy indication, e.g. CRC) to each of said sent data packets; and the receiver is then able to check if any of said transmitted packets contains transmission errors and, in case any of said received data packets contains any error due to a transmission through a poor quality transmission channel, discard said data packet and request its retransmission to the transmitter, as long as the errors occur. In some ARQ protocol implementations, the transmitter also provides identification information for each data packet sent (such as the sequence number) so that the receiver can request the retransmission of a specific packet which contains transmission errors. Examples of ARQ communication protocols schemes are stop-and-wait, go-back-N and selective repeat. FEC techniques (such as reed-solomon code or turbo code) rely on adding some error correction information to each transmitted packet which allows the receiver to detect and correct errors, to some extent, caused in the process of transmission.
There are various commonly known types of HARQ protocols: in type I HARQ the receiver discards received packets which contain transmission errors at the output of the FEC decoder and asks for retransmission of those packets. In Chase combining (CC) HARQ, the receiver stores in a memory received data packets which contain transmission errors at the output of the FEC decoder, asks for retransmission of those packets and when said packets are received again they are combined with the version of said packets previously stored in memory before providing to the FEC decoder. Combining the two received versions of the packet increases the probability of successful FEC decoding. The retransmitted data packets contain exactly the same set of coded bits as used for the initial transmission of said data packet. In incremental redundancy (IR) HARQ, additional redundant information is transmitted in each retransmission of the packet and the receiver, i.e. a retransmitted data packet may contain different coded bits as the ones used for the initial transmission of the data packet. At the receiver, the received data packets are decoded when they are received for the first time, and if unsuccessful, for each retransmission the newly received data packet will add combining gain and/or extra redundancy to the previous version stored in memory before providing to the FEC decoder. IR HARQ may use self-decodable or non self-decodable (at least in part) retransmission packets.
Due to HARQ schemes (e.g. CC and IR) which employ combining (e.g. soft-combining or code-combining) of received (retransmitted) packets with combining information of earlier non-successfully decoded versions of said packets before providing the combined packet to the FEC decoder, the dimensioning of the buffer to store HARQ data from failed decoding attempts becomes an important system architecture design issue, particularly in applications in which a transmitter establishes multiple parallel HARQ channel connections with a certain receiver, e.g. N-channel stop-and-wait HARQ. Said memory becomes quite large as the required sustainable data rates increase due to higher data rate demands of the consumer and this directly translates into a large amount of on-chip and/or off-chip memory. Using on-chip memory is expensive in terms of gate-count and using off-chip memory increases power consumption in the receiver system since large blocks of soft bits will have to be transferred from the memory, combined with the received data and stored back in the memory. Both, the size of the memory and mobile device power consumption, are particularly important in mobile wireless communications, where the HARQ protocol is widely used.
In order to reduce the memory size, there are known HARQ systems that dimension the HARQ receiver memory with a capacity below the worst case scenario (all received HARQ data are not successfully decoded and shall be maintained in memory for combining purposes) and which accept a certain amount of HARQ data loss.
U.S. Pat. No. 6,700,867 for example, discloses a HARQ communication system in which a HARQ receiver system contains a buffer with a certain predetermined space for storing received HARQ packets (received packets which have not been previously allocated in memory) and another for storing non-HARQ packets (received packets for which there is already related memory stored in the buffer). When any of said HARQ or non-HARQ packets are decoded successfully (FEC decoding) the corresponding allocated buffer space is freed and when any of said HARQ or non-HARQ packets are unsuccessfully decoded (FEC decoding), they are maintained in the buffer memory. The buffer memory space is dimensioned for a certain operating point (below the worst case) or percent of estimated received packets (HARQ or non-HARQ packets) which shall be maintained in the buffer after unsuccessful FEC decoding. When the number of unsuccessfully decoded packets increases over the estimated operating point, i.e. the buffer is full, there is not enough memory available for either storing received non-HARQ packets (before FEC decoding) or unsuccessfully decoded non-HARQ packets (after FEC decoding) and this information shall be discarded until some memory data is freed. To free memory, the HARQ receiver system relies on sending a request to a HARQ transmitter so that all packets to be transmitted (after said request) are self-decodable and therefore the probability of successful FEC decoding of received packets, which have memory allocated, increases and thus said memory can be freed. This solution though works only in HARQ receiver systems in which the transmitter and the receiver work in coordination and is thus not applicable to all HARQ systems, e.g. in which the HARQ transmitter is not adapted to react to a self-decode request from the HARQ receiver. Additionally, even if the transmitter reacts to the self-decode request message sent by the HARQ receiver, the solution does not avoid discarding valuable received or unsuccessfully decoded non-HARQ data packets. Another drawback of the above solution is that it can be only applied to incremental redundancy HARQ where at least part of the retransmissions are non self-decodable, since for Chase combining HARQ or for incremental redundancy HARQ where all the transmissions are self-decodable, it becomes useless.
PCT patent application WO 2004/062184 discloses a HARQ memory management method which does not depend on the coding type of data sent by the transmitter to free memory from the receiver buffer. The method describes providing the HARQ receiver system with a first buffer for storing received data blocks and a second buffer for storing information of unsuccessfully decoded data blocks, and when a data block is unsuccessfully decoded (e.g. FEC decoding) and there is not enough memory to store said data block in said second buffer for storing information of unsuccessfully decoded data blocks, freeing memory space from said second buffer based on characteristic parameters of already stored data blocks such as the data block sequence number or a quality indication. Although not explicitly indicated, the use of a receive buffer (the first buffer) is implicit, since the packet is first sent to the FEC decoder and then, if the decoding is unsuccessful, the packet will be stored, and therefore, meanwhile the packet needs to be stored somewhere due to the FEC decoder latency. This solution still wastes memory space for storing HARQ data blocks and presents a low data block-processing throughput due to latencies introduced in the data processing chain. Furthermore, if the decoding of the newly received packet was unsuccessful, it is then combined, and the combined packet is sent again to the FEC decoder, thus doubling the necessary cycles for decoding a packet.